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Abstract —Preventing implicit information flows by 
dynamic program analysis requires coarse approxima¬ 
tions that result in false positives, because a dynamic 
monitor sees only the executed trace of the pro¬ 
gram. One widely deployed method is the no-sensitive- 
upgrade check, which terminates a program whenever 
a variable’s taint is upgraded (made more sensitive) 
due to a control dependence on tainted data. Although 
sound, this method is restrictive, e.g., it terminates the 
program even if the upgraded variable is never used 
subsequently. To counter this, Austin and Flanagan in¬ 
troduced the permissive-upgrade check, which allows a 
variable upgrade due to control dependence, but marks 
the variable “partially-leaked”. The program is stopped 
later if it tries to use the partially-leaked variable. 
Permissive-upgrade handles the dead-variable assign¬ 
ment problem and remains sound. However, Austin 
and Flanagan develop permissive-upgrade only for a 
two-point (low-high) security lattice and indicate a 
generalization to pointwise products of such lattices. In 
this paper, we develop a non-trivial and non-obvious 
generalization of permissive-upgrade to arbitrary lat¬ 
tices. The key difficulty lies in finding a suitable notion 
of partial leaks that is both sound and permissive and in 
developing a suitable definition of memory equivalence 
that allows an inductive proof of soundness. 

I. Introduction 

Information flow control (IFC) is often used to enforce 
confidentiality and integrity of data. In a language-based 
setting, IFC may be enforced statically m, eb. sa. 
DU, [IB, 0, dynamically [3], 0], 03], 0, [2D], 00], or 
in hybrid ways 0, m, m , m- We are particularly 
interested in dynamic IFC and, more specifically, dynamic 
IFC for JavaScript, which has features like runtime code 
construction and runtime modification of scope chains that 
make static analysis difficult. 

Dynamic IFC usually works by tracking taints or labels 
on individual program values in the language runtime. A 
label represents a mandatory access policy on the value. 
For example, the label L (low confidentiality) convention¬ 
ally means that data may be read by an (unspecified 
but fixed) adversary and H (high confidentiality) means 
the opposite. More generally, labels may be drawn from 

This is an updated version of a paper of the same title published 
at the ACM Ninth Workshop on Programming Languages and Anal¬ 
ysis for Security (PLAS), 2014 (doi>10.1145/2637113.2637116). The 
update improves the permissiveness of the dynamic analysis of the 
original paper slightly. 


any lattice of policies, with higher labels representing 
more restrictive policies. A value v labeled A is written 
v W IFC analysis propagates labels as data flows during 
program execution. Flows are of two kinds. Explicit flows 
are induced by expression evaluation and variable assign¬ 
ment. For example, if either variable y or z is labeled H 
(confidential), then the result of computing y_+ z will have 
label H , which makes it confidential as well0 

Implicit flows are induced by control flow dependencies. 
For example, in the program of Listing [L] the value in 
variable x at the end of line [3] depends on the value in z 
(so the value in x at the end of line [3] must be labeled H 
if the value in z is confidential), but x is never assigned 
any expression that explicitly depends on z. To track 
such implicit flows, dynamic IFC maintains an additional 
taint, usually called the program counter taint or program 
context taint or pc, which is an upper bound on the control 
dependencies that lead to the current instruction being 
executed. In our example, if z is labeled H , then at line [3] 
pc = H because of the branch in line [2] that depends on z. 
By tracking pc, dynamic IFC can enforce that x has label 
H at the end of line [3] thus taking into account the control 
dependency. 

However, simply tracking control flow dependencies via 
pc is not enough to guarantee absence of information flows 
when labels are flow-sensitive, i.e., when the same variable 
may hold values with different labels depending on what 
program paths are executed. The program in Listing |T] 
is a classic counterexample, taken from [3]. Assume that 
z is labeled H and x and y are labeled L initially. We 
compute the final value in y as a function of the value 
in z. If 2 contains tme H , then y ends with trueU The 
branch on line [2] is not taken, so x remains false L at 
line 0] Hence, the branch on line 0 is taken, but pc = L 
at line [5] and y ends with true L . If z contains false ff , 
then similar reasoning shows that y ends with false L . 
Consequently, in both cases y ends with label L and its 
value is exactly equal to the value in z. Hence, an adversary 
can deduce the value of z by observing y at the end (which 
is allowed because y ends with label L ). So, this program 
leaks information about z despite correct use of pc. 

Handling such flows in dynamic IFC requires coarse 

x By “z is labeled H ” we actually mean “the value in z is labeled 
H". This convention is used consistently. 


e := 


1 x = false, y = false 

2 if (not(z)) 

3 x = true 

4 if (not(a;)) 

5 y = true 

Listing 1. Implicit flow from z to y 


1 x = false 

2 if (not(z)) 

3 x = true 

4 if ( y ) f() else g() 

5 x = false 

Listing 2. Impermissiveness of the NSU strategy 

approximation because a dynamic monitor only sees pro¬ 
gram branches that are executed and does not know 
what assignments may happen in alternate branches 
in other executions. One such coarse approximation 
is the no-sensitive-upgrade (NSU) check proposed by 
Zdancewic (22]. In the program in Listing [I] we upgrade 
x’s label from L to H at line[3]in one of the two executions 
above, but not the other. Subsequently, information leaks 
in the other execution (where i’s label remains L) via 
the branch on line [2 The NSU check stops the leak 
by preventing the assignment on line [3j More generally, 
it stops a program whenever a variable’s label is up¬ 
graded due to a high pc. This check suffices to provide 
termination-insensitive noninterference, a standard secu¬ 
rity property m- However, terminating a program pre¬ 
emptively in this manner is quite restrictive in practice. 
For example, consider the program of Listing [2j where z 
is labeled H and y is labeled L. This program potentially 
upgrades variable x at line G3 under a high pc, and then 
executes function f when y is true and executes function 
g otherwise. Suppose that f does not read x. Then, for 
y i—^ true L , this program leaks no information, but the 
NSU check would terminate this program prematurely at 
line [31 (Note: g may read x, so x is not a dead variable at 
line (SI) 

To allow a dynamic IFC to accept such safe executions 
of programs with variable upgrades due to high pc, Austin 
and Flanagan proposed a less restrictive strategy called 
permissive-upgrade [3]. Whereas NSU stops a program 
when a variable’s label is upgraded due to assignment 
in a high pc, permissive-upgrade allows the assignment, 
but labels the variable partially-leaked or P. The taint 
P roughly means that the variable’s content in this 
execution is H, but it may be L in other executions. 
The program must be stopped later if it tries to use or 
case-analyze the variable (in particular, branching on a 
partially-leaked Boolean variable is stopped). Permissive- 
upgrade also ensures termination-insensitive noninterfer¬ 
ence, but is strictly more permissive than NSU. For 
example, permissive-upgrade stops the leaky program of 


n | x | ei © e 2 
c := x := e | ci; c 2 | 

if e then c\ else C 2 | 
while e do c\ 

A := L | H 
pc := A 
k, l,m := A 

Fig. 1. Syntax 

Listing Q] at line 2] when z contains false ff , but it allows 
the program of Listing [5] to execute to completion when y 
contains true L . 

a) Contribution of this paper: Although permissive- 
upgrade is useful, its development in literature is incom¬ 
plete so far: Austin and Flanagan’s original paper [2], and 
work building on it, develops permissive-upgrade for only 
a two-point security lattice, containing levels L and H 
with L (Z H, and the new label P. A generalization to a 
pointwise product of such two-point lattices (and, hence, a 
powerset lattice) was suggested by Austin and Flanagan in 
the original paper, but not fully developed. As we explain 
in Section ITTT1 this generalization works and can be proved 
sound. However, that still leaves open the question of 
generalizing permissive-upgrade to arbitrary lattices. It is 
not even clear hitherto that this generalization exists. 

In Section IIVI we show by construction that a gener¬ 
alization of permissive-upgrade to arbitrary lattices does 
indeed exist and that it is, in fact, non-obvious. Specifi¬ 
cally, the rule for adding partially-leaked labels and the 
definition of store (memory) equivalence needed to prove 
noninterference are reasonably involved. On powerset lat¬ 
tices, the resulting IFC monitor is different from the result 
of the product construction, and we show that our system 
can be more permissive than the product construction in 
some cases. By developing this generalization, our work 
makes permissive-upgrade applicable to arbitrary security 
lattices like other IFC techniques and, hence, constitutes 
a useful contribution to IFC literature. 

II. Language and Basic IFC Semantics 

Our technical development is based on a simple im¬ 
perative language shown in Figure fi~FI The language’s 
expressions include constants or values (n), variables (x) 
and unspecified operators (©) to combine them. The set 
of variables is fixed upfront. Labels (A) are drawn from 
a fixed security lattice. For now, the lattice contains only 

2 Austin and Flanagan’s work on permissive-upgrade is based on a 
A-calculus with dynamic allocation, which is more general than this 
language [4|. However, our key ideas are orthogonal to the choice of 
language and generalize to the language of j4] easily. We use a simpler 
language to simplify non-essential technical details. 



Expressions: 


const: 


n k := cr(x) 


oper: 


(n, o) JJ. n 1 - (x , o) JJ. n k 

e = e' © e" (e 1 , o) JJ. n' k (e ", a) JJ. n" k n := n! © n" k := k' U k" 


(e,a) JJ. n' 


Statements: 


(ci, tr) JJ pc a" (c 2 , o") JJ pc o' 

seq: ------- if-else-t: 

( Ci 5 C2, <J) 'IJ'pc & 


(e, u) ifn A n = true ( a , o) JJ pcu A o' 
(if e then Ci else c 2 ,er) JJ pc o' 


(e, (j)JJ.n ' 4 n = false (c 2 , 0 } ^ pc uA cr' (e, cr) JJ pc rU 

if-else-f: -----:- while-f: 


n = false 


(if e then Ci else c 2 ,cr) JJ pc o' 


(while e do Ci, 0 ) JJ pc cr 


while-t: 


(e,cr) JJ.77, -4 n = true (ci,cr) JJ- pcU ^ cr" (while e do ci, cr") JJ- pc uyt cr' 

(while e do Ci,cr) JJ pc o' 

Fig. 2. Semantics 


two labels (L, H} with the ordering L \Z H; we generalize 
this later in the paper. Join (U) and meet (n) operations 
are defined as usual on the lattice. The program counter 
label pc is an element of the lattice. 

A. IFC Semantics and NSU 

The rules in Figure [5] define the big-step semantics of the 
language, including standard taint propagation for IFC: 
the evaluation relation (e, o) JJ- n k for expressions, and the 
evaluation relation (c, o) JJ. pc o' for commands. Here, o 
denotes a store, a map from variables to labeled values of 
the form n k . For now, labels k ::= A ; we generalize this 
later when we introduce partially-leaked taints. 

The evaluation relation for expressions evaluates an 
expression e and returns its value n and label k. The 
label k is the join of labels of all variables occurring in 
e (according to cr). The relation for commands executes a 
command c in the context of a store cr, and the current 
program counter label pc, and yields a new store o'. The 
function r(cr(a:)) returns the label associated with the 
value in x in store cr: If cr(a;) = n k , then r(cr(a;)) = k. We 
write J_ for the least element of the lattice. Here, J_ = L. 

We explain the rules for evaluating commands. The rule 
for sequencing ci; c 2 evaluates the command ci under store 
cr and the current pc label; this yields a new store o". It 
then evaluates the command c 2 under store o" and the 
same pc label, which yields the final store o'. 

The rules for if-else evaluate the branch condition e 
to a value n with label A. Based on the value of n, one of 
the branches ci and c 2 is executed under a pc obtained by 
joining the current pc and the label A of n. Similarly, the 
rules for while evaluate the loop condition e and execute 
the loop command ci while e evaluates to true. The pc 


_ 1 ■= r (o-(X)) pc E l (e, o) J| n m 

assn-NSU: - 7———7 - 

{x := e, cr) JJ. pc o[x >->■ n^ pc m ^] 

Fig. 3. Assignment rule for NSU 

for the loop is obtained by joining the current pc and the 
label A of the result of evaluating e. 

Rules for assignment statements are conspicuously miss¬ 
ing from Figure [2] because they depend on the strategy 
used to control implicit flows. In the remainder of this 
paper we consider a number of such rules. To start, the rule 
for assignment corresponding to the NSU check is shown 
in Figure[3] The rule checks that the label l of the assigned 
variable x in the initial store o is at least as high as pc 
(premise pc E 0- If this condition is not true, the program 
gets stuck. This is exactly the NSU check described in 
Section Q] 

B. Termination-Insensitive Noninterference 

The end-to-end security property usually established 
for dynamic IFC is termination-insensitive noninterfer¬ 
ence (TINI). Noninterference means (in a technical sense, 
formalized below) that two runs of the same program 
starting from any two stores that are observationally 
equivalent for any adversary end with two stores that are 
also observationally equivalent for that adversary. For our 
observation model, where the adversary sees only initial 
and final memories, termination-insensitive means that we 
are willing to tolerate the one-bit leak when an adversary 
checks whether or not the program terminated (for pro¬ 
grams with intermediate observable outputs, termination- 
insensitivity may leak more than one bit m . In particular, 
this discounted one-bit leak accounts for termination due 











to failure of the NSU or permissive-upgrade check. Tech¬ 
nically, termination-insensitivity amounts to considering 
only properly terminating runs in the noninterference 
theorem. 

Store equivalence is formalized as a relation ~_ 4 , indexed 
by lattice elements A. representing the adversary. 

Definition 1. Two labeled values n\ anc 1 n 2 l are B- 
equivalent, written n\ rif, iff either: 

1) (k = m) C A and n\ = n 2 or 

2) k % A and m% A 

This definition states that for an adversary at security 
level A, two labeled values n\ and nf are equivalent iff 
either A can access both values and ni and n 2 are equal, 
or it cannot access either value (k % A and m % A). The 
additional constraint k = m in clause (1) is needed to 
prove noninterference by induction. Note that two values 
labeled L and H respectively are distinguishable for the 
L-adversary. 

Definition 2. Two stores <7\ and 02 are A-equivalent, 
written ai 02 , iff for every variable x, cr\{x) ~.a 02 ( 2 :). 

The following theorem states TINI for the NSU check. 
The theorem has been proved for various languages in the 
past; we present it here for completeness. 

Theorem 1 (TINI for NSU). With the assignment rule 
from Figure [3J if a 1 02 and (c, <j\ ) JJ. pc a' x and 

{c,cr 2 ) JJ-p C cr' 2 , then a[ er'. 

Proof: Standard, see e.g., [3] ■ 

Although we have restricted our security lattice to two 
elements L and H , the rules of Figures [2] and [BJ the 
definition of equivalence above and the theorem above (for 
NSU) are all general and work for arbitrary lattices. 

III. Permissive-Upgrade on a Two-Point Lattice 

As described in Section [H the NSU check is restrictive 
and halts many programs that do not leak information. To 
improve permissiveness, the permissive-upgrade strategy 
was proposed as a replacement for NSU by Austin and 
Flanagan [3]. However, that development is limited to a 
two-point lattice L C H and to pointwise products of 
such lattices. We present the key results of [II here (using 
modified notation and for our language) and then build a 
generalization of permissive-upgrade to arbitrary lattices 
in the next section. Readers should keep in mind that in 
this section, the lattice has only two levels: L (public) and 
H (confidential). 

We introduce a new label P for “partially-leaked”. We 
allow labels k,l,m on values to be either elements of the 
lattice ( L,H ) or P. The pc can only be one of L,H 
because branching on partially-leaked values is prohibited. 
This is summarized by the revised syntax of labels in 
Figured! The figure also lifts the join operation U to labels 
including P. Note that joining any label with P results in 
P. For brevity in definitions, we also extend the order c 


A:= 

L 

H 

pc := 

A 


k, l, m := 

A 

P 

k U k = 

k 


LUH = 

H 


PUP = 

P 


HUP = 

P 



Fig. 4. Syntax of labels including the partially-leaked label P 

to L c H d P. However, P is not a new “top” member 
of the lattice because it receives special treatment in the 
semantic rules. 

The intuition behind the partial-leak label P is the 
following: 


A variable with a value labeled P may have been 
implicitly influenced by U-labeled values in this exe¬ 
cution, but in other executions (obtainable by chang¬ 
ing P-labeled values in the initial store), this implicit 
influence may not exist and, hence, the variable may 
be labeled L. 


The rule for assignment with permissive-upgrade is 
l := r(<j(a;)) (e, cr) JJ-n m 

assn-PUS: - r — 

(x := e, a) (! pc a[x i-A n } 

where k is defined as follows: 

) m if pc = L 

m U H if pc = H and l = H 
P otherwise 

The first two conditions in the definition of k correspond 
to the NSU rule (Figure 0). The third condition applies, 
in particular, when we assign to a variable whose initial 
label is L with pc = H. The NSU check would stop 
this assignment. With permissive-upgrade, however, we 
can give the updated variable the label P, consistent with 
the intuitive meaning of P. This allows more permissive¬ 
ness by allowing the assignment to proceed in all cases. 
To compensate, we disallow any program (in particular, 
an adversarial program) from case analyzing any value 
labeled P. Consequently, in the rules for if-then and 
while (Figure O, we require that the label of the branch 
condition be of form A, which does not include P. 

The noninterference result obtained for NSU earlier 
can be extended to permissive-upgrade by changing the 
definition of store equivalence. Because no program can 
case-analyze a P-labeled value, such a value is equivalent 
to any other labeled value. 





Definition 3. Two labeled values n\ and rif are equiva¬ 
lent, written n k ~ nf, iff either: 

1) (k = to) = L and n\ = r /2 or 

2) k = to = H or 

3) k = P or to = P 


Theorem 2 (TINI for permissive-upgrade with a two- 
point lattice). With the assignment rule assn-PUS, if 
o i ~ (72 and (c, <7i) JJ. pc o( and (c, of) JJ-pc erf then o( ~ of 


Proof: See [3]. ■ 

Note that the above definition and proof are specific to 
the two-point lattice. 

b) Generalization from Austin and Flanagan 

point out that permissive-upgrade on a two-point lattice, 
as described above, can be generalized to a pointwise 
product of such lattices. Specifically, let X be an index 
set — these indices are called principals in [3]. Let a label 
l be a map of type X —>• {L,H, P} and let the subclass 
of pure labels contain maps A, pc of type X —> {L,H}. 
The order [I and the join operation U can be generalized 
pointwise to these labels. Finally, the rule assn-PUS can 
be generalized pointwise by replacing it with the following 
rule: 


assn-PUS’: 


l := r(cr(x)) (e, o) f n m 
(x := e, o) lJ.p C cr[ir n k ] 


where k is defined as follows: 

{ m(a) if pc(a) = L 

m(a ) U H if pc(a) = H and 1(a) = H 
P otherwise 

ft can be shown that for any semantic derivation in 
this generalized system, projecting all labels to a given 
principal yields a valid semantic derivation in the system 
with a two-point lattice. This immediately implies nonin¬ 
terference for the generalized system, where observations 
are limited to individual principals. 


Definition 4. Two labeled values n\ and nf are a- 
equivalent, written n\ « a n™, iff either: 

1) k(a) = m(a) = L and n\ = ni or 

2) k(a) = m(a) = H or 

3) k(a) = P or m(a) = P 


Theorem 3 (TIN! for permissive-upgrade with a product 
lattice). With the assignment rule assn-PUS’, if o\ ~° 02 
and (c, of) Jj-p C o( and (c, of) JJ- pc cf' 2 , then o( « a of 


Proof: Outlined above. ■ 

e) Remark: This generalization also makes sense if 
the principals are pre-ordered by a relation, say, <, with 
a < b meaning that “if a has access, then b must have 
access”, ft can be proved that the following is an invariant 
on all labels l that arise during program execution: ((a < 
b) A ( 1(a) = L)) =t- 1(b) = L. Hence, the intuitive meaning 
of the order < is preserved during execution. 

This generalization of the two-point lattice to an ar¬ 
bitrary product of such lattices is interesting because an 


1 if (x') 

2 z = yi 

3 else 

4 2 = 3/2 

5 if (*1) 

6 z = x 1 

7 if (not(*2)) 

8 z = x 2 

9 if (z) 

10 w = z 

Listing 3. Example explaining rule assn-2 


arbitrary powerset lattice can be simulated using such a 
product. However, this still leaves open the question of 
constructing a generalization of permissive-upgrade to an 
arbitrary lattice. We develop such a generalization in the 
next section. 

IV. Permissive-Upgrade on Arbitrary Lattices 

The generalization of permissive-upgrade described in 
this section applies to an arbitrary security lattice. For 
every element A of the lattice, we introduce a new label 
A* which means “partially-leaked A ”, with the following 
intuition. 


A variable labeled A* may contain partially-leaked 
data, where A is a lower-bound on the *-free labels 
the variable may have in alternate executions. 


The syntax of labels is listed in Figure [6] Labels k, l, to 
may be lattice elements A or *-ed lattice elements A* . In 
examples, we use suggestive lattice element names L , M, H 
(low, medium, high). Labels of the form A are called *- 
free or pure. Figure 0 also defines the join operation U on 
labels, which is used to combine labels of the arguments of 
0. This definition is based on the intuition above. When 
the two operands of 0 are labeled A\ and A2*, A\ U A2 is 
a lower bound on the pure label of the resulting value in 
any execution (because A 2 is a lower bound on the pure 
label of A2* in any run). Hence, A\ U A2* = (A\ U ^ 2 )*- 
The reason for the definition A\* U A2* = (A\ U A2)* is 
similar. 


Our rules for assignment are shown in Figure El They 
strictly generalize the rule assn-PUS for the two-point 
lattice, treating P = L*. Rule assn-1 applies when the 
existing label of the variable being assigned to is A x or 
A x * and pc U A x - The key intuition behind the rule is 
the following: If pc U A x , then it is safe to overwrite the 
variable, because A x is necessarily a lower bound on the 
(pure) label of x in this and any alternate execution (see 


the framebox above). Hence, overwriting the variable 


cannot cause an implicit flow. As expected, the label of 
the overwritten variable is pc U m, where to is the label of 





I := F(cr(x)) (e, a) Jj. n m l = A x V l = A x * pc C A x k := pc U m 

isn-1: - r - 

(x := e, a) JJ- pc a[x pa n ] 

l := r(cr(x)) (e, a) JJ. n m l = A x V / = A x * pc % A x k := {{pc U m) n A x )* 

{x := e, a) JJ- pc a[x pa n k ] 

Fig. 5. Assignment rules for the generalized permissive-upgrad(J3 



w = false 

1,1 , x\ = true Ll , yi = false iWl , y 2 = true iW2 


x' = true L 

X 2 = true^ 2 

x f 

X2 

= false L 
= false 1,2 



assn -2 with k := A x * 

assn -2 with k := ((pc U m) n A x )* 

if (x') 
z = y 1 

else 

if-branch taken, pc = L' 
z = f alse M i 

else-branch taken, pc = L' 

else-branch taken, pc = L' 

2 = 2/2 


z = true** 2 

z = true M2 

if (xi) 

branch taken, pc = L\ 

branch taken, pc = L\ 

branch taken, pc = L 1 

Z = X 1 

z = true 1 ' 1 

z = true M 2* 

z = true 1. 

if (not(x 2 )) 

branch not taken 

branch taken, pc = L 2 

branch taken, pc = L 2 

II 


z = false 1 ' 2 

z = false 1. 

if (z) 

branch taken, pc = L\ 

branch not taken 

execution halted 

w = z 

w = true Ll 



Result 

w = true^ 1 

w = false 1 ' 1 (leak) 

execution halted (no leak) 


TABLE I 

Execution steps in two runs of the program from Listing [3] with two variants of the rule assn-2 


A:= L\M | ... H 
pc := A 

k,l,m := A | .A* 


Ai U A2* :— (Ai LI A2)* 

Ai* U A2* '■= (Ai U A2)* 

Fig. 6. Labels and label operations 


H 



L 


Fig. 7. Lattice explaining rule assn-2 


the value assigned to x. 

Rule assn -2 applies in the remaining case — when 
pc % A x . In this case, there may be an implicit flow, so 
the final label on x must have the form A* for some A. 
The question is which A? Intuitively, it may seem that one 
could choose A = A x , the pure part of the original label 

3 In the original paper, k := (pc fl Ax)* in the rule for assn-2 


of x. The final label on x would be A x * and this would 
satisfy the intuitive meaning of * written in the 
above. Indeed, this intuition suffices for the 
lattice of Section Hill However, for a more general lattice, 
this intuition is unsound, as we illustrate with an example 
below. The correct label is {{pc U m) n A x )* . (Note that 
this correct label is independent of the label m of the value 
assigned to x. This is sound because x is *-ed and cannot 
be case-analyzed later, so the label on the value in it is 
irrelevant.) 

d) Example: We illustrate why we need the label 
k := {{pc U m) n Ax)* instead of k := A x * in rule assn- 
2 . Consider the lattice of Figure [ 7 ] and the program of 
Listing[ 3 J Assume that, initially, the variables z, w, xi, x ', 
X2, 2/i and 2/2 have labels H 1 L 1, Li, L ', L2 , M\ and M2, 
respectively. Fix the attacker at level L\. Fix the value of 
X\ at true Ll , so that the branch on line [ 7 ] is always taken 
and line ED is always executed. Set 2/1 | —t false Ml ,2/2 
true M2 ,w 1—^ false Ll initially. The initial value of z is 
irrelevant. Consider two executions of the program starting 
from two stores <j\ with x' pa true L , X2 pa true ^ 2 and 
<72 with x' pa false L , X2 pa false 1 " 2 . Note that because 
L' and L2 are incomparable to L\ in the lattice, ay and 
a2 are equivalent for L\. 

We show that requiring k := A x * in rule assn -2 causes 
an implicit flow that is observable for L\. The intermediate 
values and labels of the variables for executions starting 
from (t 1 and <72 are shown in the second and third columns 
of Tabled] Starting with cy, line[ 7 ]is executed, but line|l]is 
not, so z ends with false Ml at line [ 5 ] (rule assn -1 applies 


framebox 

two-point 
















at line [2]). At line [Gl ~ contains true Ll (again by rule assn- 

1) and line [5] is not executed. Thus, the branch on line 0 is 
taken and w ends with true Ll at Kne llOl Starting with 02 , 
lined] is not executed, but lined] is, so z becomes true M2 
at line [5] (rule assn-1 applies at lined]). At lined] rule assn- 
2 applies, but because we assume that k := A x * in that 
rule, z now contains the value true M2 . As the branch 
on line [7] is taken, at lined] z becomes false 1,2 by rule 
assn-1 because L2 E M2. Thus, the branch on line^is not 
taken and w ends with false Ll in this execution. Hence, 
w ends with true 1,1 and false Ll in the two executions, 
respectively. The attacker at level Li can distinguish these 
two results; hence, the program leaks the value of x' and 
X 2 to L 1 . 

With the correct assn-2 rule in place, this leak is avoided 
(last column of TableUJ. In that case, after the assignment 
on lined] in the second execution, z has label {{L\ ULi) n 
M 2 )* = L*. Subsequently, after line dl z gets the label 
L*. As case analysis on a *-ed value is not allowed, the 
execution is halted on lined] This guarantees termination- 
insensitive noninterference with respect to the attacker at 
level L 1 . 

A. Store equivalence 

To prove noninterference for our generalized permissive- 
upgrade, we define equivalence of labeled values relative to 
an adversary at arbitrary lattice level A. The definition is 
shown below. We explain later how it is obtained, but we 
note that clauses (3)-(5) here refine clause (3) of Defini- 
tiondlfor the two-point lattice. The obvious generalization 
of clause (3) of Definition dl n i n T whenever 
either k or m is *-ed — is too coarse to allow us to 
prove noninterference inductively. For the degenerate case 
of the two-point lattice, this definition also degenerates to 
Definition dl (there, A is fixed at L, P = L * and only L 
may be *-ed). 

Definition 5. Two values n\ and n™ are A-equivalent, 
written n\ nVf, iff either 

1) k = m = A! E A and n\ = 712 , or 

2) k = A' % A and m = A" E A, or 

3) k = Ai* and m = A 2 *, or 

4 ) k = Ai* and m = A 2 and (A 2 % A or A\ E A 2 ), or 

5) k = A\ and m = A 2 * and (A\ % A or ^2 Q Ai) 

We obtained this definition by constructing (through 
examples) an extensive transition graph of pairs of labels 
that may be assigned to a single variable at corresponding 
program points in two executions of the same program. 
Our starting point is label-pairs of the form (A, A). We 
discovered that this characterization of equivalence is both 
sufficient and necessary. It is sufficient in the sense that 
it allows us to prove TINI inductively. It is necessary 
in the sense that example programs can be constructed 
that end in states exercising every possible clause of 
this definition. A technical appendix, available from the 
authors’ homepages, lists these examples. 


B. Termination-Insensitive Noninterference 

Using the above definition of equivalence of labeled 
values, we can prove TINI for our generalized permissive- 
upgrade. A significant difficulty in proving the theorem 
is that our definition of is not transitive. The same 
problem arises for the two-point lattice in [3]. There, the 
authors resolve the issue by defining a special relation 
called evolution. Here, we follow a more conventional 
approach based on the standard confinement lemma. The 
need for evolution is averted using several auxiliary lem¬ 
mas that we list below. Detailed proofs of all lemmas and 
theorems are presented in our technical appendix. 

Lemma 1 (Expression evaluation). If {e,o\) JJ- n^ 1 and 
(e, 02 ) JJ- n 2 2 and o\ 02 , then n^ 1 n 2 2 . 

Proof: By induction on e. ■ 

Lemma 2 (*-preservation). If(c,o) JJ. pc a' andT(o{x)) = 
A* and pc E A, then T(cr , (a;)) = A'* and A' E A. 

Proof: By induction on the given derivation. ■ 

Corollary 1. If (c,o) JJ. pc o' and r(cr(a:)) = A* and 
r(cr , (x)) = A!, then pc E A. 

Proof: Immediate from Lemma [2] ■ 

Lemma 3 (pc-lennna). If (c,o) J) pc o' and T(cr , (a;)) = A , 
then o(x) = o'(x) or pc E A. 

Proof: By induction on the given derivation. ■ 

Corollary 2. If (c,o) JJ- pc o' and r(cr(a:)) = A * and 
r(cr , (x)) = A', then pc E A' . 

Proof: Immediate from Lemma [3] ■ 

Using these lemmas, we can prove the standard confine¬ 
ment lemma and noninterference. 

Lemma 4 (Confinement Lemma). If pc E A and 
(c,o) V o', then o o'. 

Proof: By induction on the given derivation. ■ 

Theorem 4 (TINI for generalized permissive-upgrade). 
If o\ 02 and (c, of) JJ. pc er( and ( 0 , 02 ) JJ- pc o' 2 , then 
o 1 ~a 02- 

Proof: By induction on c. ■ 

C. Incomparability to the Generalization of Section 1 7771 

We have two distinct and sound generalizations of 
the original permissive-upgrade for the two-point lattice: 
The generalization to pointwise products of two-point 
lattices or, equivalently, to powerset lattices as described 
in Section eh and the generalization to arbitrary lattices 
described earlier in this section. For brevity, we call these 
generalizations puP (Section EH and puA (Section 113, 
respectively (P and A stand for powerset and arbitrary, 
respectively). Since both puP and puA apply to power- 
set lattices, an obvious question is whether one is more 
permissive than the other on such lattices. We show here 
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Fig. 8. A powerset/product lattice 

1 if (y) 

2 z = 2 

3 x = y + z 

4 if (y) 

5 x = 3 

6 if ( x ) 

7 y = 5 

Listing 4. Example where puA is more permissive than puP 


that the permissiveness of puP and puA on powerset 
lattices is incomparable — there are examples on which 
each generalization is more permissive than the other. We 
explain one example in each direction below. Roughly, 
incomparability exists because puP tracks finer taints (it 
tracks partial leaks for each principal separately), but 
puA’s rules for overwriting partially-leaked variables are 
more permissive. 

We use the powerset lattice of Figure [5] for our example. 
This lattice is the pointwise lifting of the order L C H 
to the set S = {L,H} x {L,H}. For brevity, we write 
this lattice’s elements as LL, LH, etc. When puP is 
applied to this lattice, labels are drawn from the set 
{L, H, P} x {L, H, P}. We write these labels concisely as 
LP, HL, etc. For puA, labels are drawn from the set SUS*. 
We write these labels LH, LH*, etc. Note that LH* parses 
as (LH)*, not L(H*) (the latter is not a valid label in puA 
applied to this lattice). 

e) Example: We start with an example program 
which executes completely under puA, but gets stuck un¬ 
der puP (since puA is sound, there is no actual information 
leak in the program). This example is shown in Listing 0] 
Assume that x, y and z have initial labels LL, HH and 
LH, respectively and that y <->• true ffff , so the branches 
on lines [T] and H] are both taken. The initial values of x and 
z are irrelevant but their labels are relevant. 

Under puP, z obtains label PH at line [2] by rule assn- 
PUS’. At line El x obtains the label (HH) U (PH) = PH. 
At line[5l the label of x stays PH by rule assn-PUS’. At 
line EE the program halts because the branch condition ads 
label contains P. 

On the other hand, under puA, the program executes 
to completion. At line [2j z obtains the label (((HH) U 
(LL))n(LH))* = LH* by rule assn-2. At lineEE x obtains 
the label (HH) U (LH*) = HH*. At line 0 the label of 
x changes to HH: the pc at this point (equal to the label 
of y) is HH, so rule assn-1 applies. Since HH is pure, the 


1 if (y) 

2 x = z 

3 if (z) 

4 x = z 

5 if (x) 

6 z = x 

Listing 5. Example where puP is more permissive than puA 


program does not stop at line EE 

Hence, on this example, puA is more permissive than 
puP. 

f) Example: Next, consider the program in Listing[5] 
For this program, puP is more permissive than puA. 
Assume that x, y and z have initial labels LL, HL 
and LH, respectively and that the initial store contains 
y tr-ae HL ,z i-A true^, so the branches on lines [L] 
and EE are both taken. The initial value in x is irrelevant 
but its label is important. 

Under puA, x obtains label (((HL) U (LH)) n (LL))* = 
LL* at lineElby rule assn-2. At line[4j the same rule applies 
but the label of x remains LL*. When the program tries 
to branch on x at lineO it is stopped. 

In contrast, under puP, this program executes to com¬ 
pletion. At line [2j the label of x changes to PH by rule 
assn-PUS’. At lineEfl the label changes to LH because pc 
and the label of z are both LH. Since this new label has 
no P, line EE executes without halting. 

Hence, for this example, puP is more permissive than 

puA. 

V. Related Work 

We directly build on, and generalize, the permissive- 
upgrade check of Austin and Flanagan |4]. Earlier sections 
describe the connection of that work to ours. In recent 
work, we implemented the permissive-upgrade check for 
JavaScript’s bytecode in the WebKit browser engine [S]. 
Our formalization in that work is limited to the two-point 
lattice, and generalizing that formalization motivated this 
paper. In working with JavaScript bytecode, we found 
permissive-upgrade indispensable: The source-to-bytecode 
compiler in WebKit generates assignments to dead vari¬ 
ables under high pc, which halts program execution if 
the no-sensitive-upgrade check (NSU) is used instead of 
permissive-upgrade. 

The permissive-upgrade check is just one of many ways 
of avoiding implicit flows in dynamic IFC when labels 
on variables are flow-sensitive (not fixed upfront). A pre¬ 
cursor to the permissive-upgrade is the NSU check, first 
proposed by Zdancewic |2Sj. A different way of handling 
the problem of implicit flows through flow-sensitive labels 
is to assign a (fixed) label to each label; this approach 
has been examined in recent work by Buiras et al. in 
the context of a language with a dedicated monad for 
tracking information flows \J\. The precise connection 
between that approach and permissive-upgrade remains 


unclear, although Buiras et al. sketch a technique related 
to permissive-upgrade in their system, while also noting 
that generalizing permissive-upgrade to arbitrary lattices 
is non-obvious. Our work confirms the latter and shows 
how it can be done. 

Birgisson et al. [Bj describe a testing-based approach 
that adds variable upgrade annotations to avoid halting 
on the NSU check in an implementation of dynamic IFC 
for JavaScript m Hritcu et al. improve permissiveness by 
making IFC errors recoverable in the language Breeze M- 
This is accomplished by a combination of two methods: 
making all labels public (by upgrading them when neces¬ 
sary in a public pc) and by delaying exceptions. 

Finally, IFC with flow-sensitive labels can be enforced 
statically or using hybrid techniques that combine static 
and dynamic methods m, m- Russo et al. m show 
formally that the expressive power of sound flow-sensitive 
static analysis and sound flow-sensitive dynamic monitors 
is incomparable. Hence, there is merit to investigating 
hybrid approaches. 

VI. Conclusion 

Permissive-upgrade is a useful technique for avoiding 
implicit flows in dynamic information flow control. How¬ 
ever, the technique’s initial development was limited to a 
two-point lattice and pointwise products of such lattices. 
We show, by construction, that permissive-upgrade can be 
generalized to arbitrary lattices and that the generaliza¬ 
tion’s rules and correctness definitions are non-trivial. 
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Appendix 

Assumptions: 

1 is a variable with label L 
m is a variable with label M 
h is a variable with label H 
1* is a variable with label L* 

L C M C H 

and we assume the attacker at level L. I represents the 
labels that are above the level of the attacker. 

The table shows example programs for the transition 
from low-equivalent values to low-equivalent values. First 
column and first row of the table represents all the possible 



i,i 

*lV2 

£i,h* 

4V2* 

h,h 

ep,h 

£i A 2 * 

£,e 

- 

if (h) 

xl = 1 

if GO 

xl = 1 

if GO 

xl = 1 
else 
xl = 1 

xl = h 

xl = m 

if GO 

xl = 4 
if (m) 
xl = 1* 

xl = m 
if(h) 
xl = 4 

if ( m ) 

xl = 1* 


xl = 1 

- 

xl = 1 
if(h) 
xl = 1 

if GO 

xl = 1 

xl = h 

xl = m 
if (h) 
xl = 1 

if ( m ) 

xl = 1* 

xl = m 

if GO 

xl = 1 

if ( m ) 

xl = 1* 

£i,h* 

xl = 1 

xl = 1 

if GO 

xl = 1 

- 

if GO 

xl = 1 

xl = h 

xl = m 

if (h) 

xl = 1 

if ( m ) 

xl = 1* 

xl = m 

if (h) 

xl = 1 

if ( m ) 

xl = 1* 

IPAA 

xl = 1 

xl = 1 
if (h) 
xl = 1 

xl = 1 
if (h) 
xl = 1 

- 

xl = h 

xl = m 

if GO 

xl = 1 

if (m) 

xl = 1* 

xl = m 

if GO 

xl = 1 

if (m) 

xl = 1* 

tlA 2 

xl = 1 

xl = 1 
if (h) 
xl = 1 

xl = 1 
if (h) 
xl = 1 

xl = 1 
if (h) 
xl = 1 
else 
xl = 1 

- 

xl = m 

if (h) 

xl = 1 

if ( m ) 

xl = 1* 

xl = m 

if GO 

xl = 1 

if (m) 

xl = 1* 


xl = 1 

xl = 1 
if (h) 
xl = 1 

xl = 1 
if (h) 
xl = 1 

xl = 1 
if (h) 
xl = 1 
else 
xl = 1 

xl = h 

- 

xl = m 

if GO 

xl = 1 

if (m) 

xl = 1* 

h,h* 

xl = 1 

xl = 1 
if (h) 
xl = 1 

xl = 1 
if (h) 
xl = 1 

xl = 1 
if (h) 
xl = 1 
else 
xl = 1 

xl = h 

xl = m 

if (h) 

xl = 1 
if (m) 
xl = 1* 

- 


TABLE II 

Examples for all possible transitions of low-equivalent to low-equivalent values 


ways in which two values can be low-equivalent (from 
defintion [5]). 

A. Proofs and Results 

Lemma 1. Expression Evaluation Lemma 

If & 1 

(e,ai) (I nf 1 , 

(e,cr 2 ) U- n 2 2 , 
then n kl n 2 2 ■ 

Proof: Proof by induction on the derivation and case 
analysis on the last expression rule. 

1) const: ni = ?r 2 = n and k\ = fc 2 =_L. 

2 ) var: As ay cr 2 , \/x.ai(x) = n kl cr 2 (a;) = n 2 2 . 

3) oper: IH1: If (ei,CTi) JJ- nf 1 , (ei,<r 2 ) nf 2 , m 

. -i lk\ fk ' 0 

<72, then n-^ n 2 . 

IH2: If (e 2 ,cri) n[ kl , (e 2 ,er 2 ) |1 nf" 2 , cti ~.a cr 2 , 

ilk',' nk'd 

then n, n 2 . 

T.S. n^ 1 n 2 2 , where ni = n[ © n", n 2 = n 2 © n 2 


and fci = U fc", fc 2 = fc 2 U fc 2 . 

As (ji <T 2 , from IH1 and IH2, nf 1 nf 2 and 

Ilk',' llkit 

n x ~ A n 2 . 

Proof by case analysis on low-equivalence definition 
for nf 1 ~ A nf 2 followed by case analysis on low- 
equivalence definition for n” kl n 2 2 . 

■ 

Lemma 2. ^-preservation Lemma 
Vx.// (c, ex) §p C a’, T(ct(x)) = A* and pc % A, then 

r(cr'(x)) =A'*AA'QA 

Proof: Proof by induction on the derivation and case 
analysis on the last rule. 

1) skip : a = ex'. 

2) assn-1: As pc % A, these cases do not apply. 

3) assn-2: From the premises, for x in statement c, 
r(cr'(x)) = ((pc U m) n A)* = A 1 . Thus, A! C A. 

For any other y, a(y) = ex'(y). Thus, A' = A. 

















4) seq : IH1 : Vs.If (c,cr) J| pc cr", r(cr(s)) = A* and 
pc % A, then r(<r"(a;)) = A A A" E A 

IH2 : Vs.If (c, cr") JJ- pc a', T(a"(x)) = A!'* and pc % 
A" , then r (o' (s) ) = A!* A A! E A" 

Thus, from IH1 and IH2, F(cr'(a;)) = A'* A A' E A. 

5) if-else: Let k = A”. 

IH: Vs.If (c, a) JJ-pcLU" cr', r(cr(s)) = A* and pc U 
A” E A , then r(cr'(s)) = A'* A A! E A 
As pc E A , so pc U A" E A. 

Thus from IH, r(cr'(s)) = A* A A E A 

6) while-t: Let k = A e . 

IH1: Vs.If (c, cr) JJ-p C i_U e cr", r(cr(s)) = A and pc U 
Ae E A, then r(cr"(s)) = A'* A A" E A 
IH2: Vs.If (c,a") i). pcUAe o', ]>"(&)) = A"* and 
pc U A E A then T(cr'(s)) = A 1 * A A' E A 
As pc E A, so pc u A E A. 

Thus from IH1 and IH2, r(er'(s)) = A* A A E A 

7) while-f : a = a'. 


Lemma 3. pc Lemma 

If (c, cr) Jj-pc o', then Vx.T(cr' (x)) = A => (ct(s) = 
cr'(s)) V pc E A. 


Proof: Proof by induction on the derivation and case 
analyis on the last rule. 

• skip: cr(s) = cr'(s). 

• assn: For s in the statement c, by premises, A = pc U 
A e . Thus, pc E A. 

For any other y s.t. F(cr'(y)) = A, a(y) = <r'(y). 

• seq: IH1: If (c, a) if pc cr", then Vs.F(cr"(s)) = A" =>■ 
(cr(s) = o"(x)) VpcC A". 

IH2: If (c, cr") JJ. pc cr', then Vs.F(c7 , (s)) = A => 
(o"(x) = cr'(s)) V pc E A. 

From IH2, if ct"(s) / cr'(x), then pc E A. 

If o"{x) = cr'(s), then from IH1: 

— If <t(s) = a"(x): cr(s) = cr'(s). 

— If u(s) E a"(x): pc E A', where A' = r(cr"(s)). 
As cr"(s) = cr'(x), A" = r(cr / (s)) = A. Thus, 
pc E A. 

• if-else: IH: If (c, cr) JJ.p cL u e cr', then Vs.r(tj'(s)) = 
A => (o(x) = o'(x)) V pc U A e E A. 

From IH, either (cr(s) = cr'(x)) or pcUA e E A. Thus, 
(cr(s) = cr'(x)) V pc E A. 

• while-t: IH1: If (c, cr) JIpcuA, cr", then Vs.r(cr"(s)) = 
A" =» (<t(x) = cr"(s)) V pc E A". 

IH2: If (c, cr") -U-pcu^te cr', then Vs.F(cr'(s)) = A =>■ 
(cr"(s) = cr'(s)) V pc E A. 

From similar reasoning as in “seq”, we have either 
a(x) = cr'(s) or pc U A e E A. Thus, cr(x) = cr'(s) V 
pc E A. 

• while-f: er(s) = cr'(s). 


Lemma 4. Confinement Lemma //pc E A, (c, cr) JJ. pc cr', 
f/ien cr ~_4 cr'. 


Proof: Proof by induction on the derivation and case 
analysis on the last rule. 

1 ) skip : cr = cr'. 

2 ) assn: Let Xi = v^ and Xf = vJ, s.t fcj = A,; V k, = 

A*. 

• pc E A : As pc E A, A,- E A. By premises of 
assn, kf = A/ V kf = A/*, where A/ = pc U A e - 
As pc E A, A/ E A. Thus, by definition [5) 2, [5)3, 
04 or 05, Xi ~ A Xf. 

• pc E A,; : By premise, kf = ((pc U to) n A)*- 
Thus, Af E A and by definition 03 or 05 

^ A *£/• 

3) seq : IH1: cr cr" and IH2: cr" cr'. T.S : a ~ A 
cr'. 

For all x G dom(a), respective x" G dom(a ") and 
respective x’ G dom(a'), x ~ A x" and x" ~ A x’. 

To show: x x'. 

Let x = v ^ 1 , x" = v % 2 , x' = U3 3 , where k± = Ai V 
fci = Ai*, k 2 = A 2 V fc 2 = A 2 * and fc 3 = A3 V k 3 = 
A 3 *. 

Case-analysis on definition 0 for IH1. 

• (ki = kf) = A' E A A q = » 2 : By IH 2 and 
definition 0 we have 

a) (k 2 = fe) = A' E A A = w 3 (case 1): 
Transitivity of equality, (k\ = fc 3 ) = A' E 
A A vi = V 3 . Thus, x ~ A x'. 

b) k 2 = A' and k 3 = A 3 * A A 3 E A' E A (case 
5): By definition 05 x ~ A x'. 

• k\ = Ai E -4 A k 2 = Ai E A: By IH2, either 

a) k 2 = A 2 E A A /c 3 = A 3 E A By defini¬ 
tion 02 , x 2 /. 

b) fc 2 = A 2 E Vl A fc 3 = A 3 *: Ai E A Thus, by 

definition 05, a; 2 ;'. 

• fc-i = Ai* A k 2 = A 2 *: By IH2, we have 

a) k 2 = A 2 * A fc 3 = A 3 * (case 3): By defini¬ 
tion 03, x ~.a 2 :'. 

b) k 2 = A 2 * A fc 3 = A 3 A (A 3 E A) (case 4): By 

definition 04, x x'. 

c) k 2 = A 2 * A k 3 = A 3 A(A 2 E A 3 ) (case 4): By 
corollary 0 pc E A 2 . As pc E an d A E 
A 3 , so A 3 E A. By definition 04, x 2;'. . 

• ki = Ai* A k 2 = A 2 s.t. (A 2 E A) (case 4): 
Either 

— k 2 = A 2 E A A fc 3 = A 3 E A: By defini¬ 
tion 04, 2 ; 2 :'. 

— k 2 = A 2 E A A fc 3 = A 3 *: By definition 03, 

2; . t '. 

• ki = A\* A k 2 = A 2 s.t. (Ai E A 2 ) (case 4): 

— k 2 = fc 3 = A 2 : By definition 04, 2 : 2 :'. 

— k 2 = A 2 E A A fc 3 = A 3 % A. By defini¬ 
tion 04, a; ~ A x'. 

— k 2 = A 2 E A A fc 3 = A 3 *: By definition 03, 

2 ; x'. 


• k\ = A\ A fc 2 = A 2 * s.t. (Ai % A): By IH2, we 
have 

a) k '2 = A 2 * A k;i = A 3 * (case 3): By defini¬ 
tion's, x x'. 

b) k 2 = A 2 * A fc 3 = A 3 s.t. (A 3 E A) (case 4): 
By definition [5)2, x ~ A x'. 

c) k 2 = A 2 * A k 3 = A 3 s.t. (A 2 E A 3 ) (case 

4): By corollary |T| pc E A 2 . As pc E A and 
A 2 E A 3 , so A 3 E A. By definitional 2, x ~a 
x'. 

• k\ = Ai A fc 2 = A 2 * s.t. (A 2 E Ai): Also, (A 2 E 
Ai E A). By IH2, we have 

a) fc 2 = A 2 * A fc 3 = A 3 * (case 3): As A 2 E A 
and pc E A, pc E A 2 . By lemma H A 3 E 
A 2 . Thus, A 3 E A 2 E Ai. By definition [5] 5, 
x ~.a x'. 

b) fc 2 = A 2 * A fc 3 = A 3 (case 4): As A 2 E A 
and pc E A, pc E A 2 . But, by corollary [ 1 ] 
pc E A 2 . By contradiction, this case does not 
hold. 

4) if-else : IH : fc = A'. If (pcU A') E A, then er er'. 
As pc E A, pc U A' E A. Thus, by IH, <7 cr'. 

5) while-t: IH 1 : k = A'. If (pcUA') E A, then er er'. 
As pc E A, pc U A' E A. Thus, by IH 1 , er ~_4 er". 
IH2 : k = A'. If (pc U A') E A, then er' ~a ct". 

As pc E A, pc U A' E A. Thus, by IH, er" er'. 
Therefore, er er" and er" er'. 

(Reasoning similar to seq.) 

6 ) while-f : er = er' 

■ 

Theorem 1. Termination-insensitive non-interference 
If o 1 ~.A c 2 , 

(c,cri) JJ-pc erf, 

(c,cr 2 ) JJ-pc 0 ” 2 , 
then 

„ r / _/ 

CTi CT 2 - 

Proof: By induction on the derivation and case anal¬ 
ysis on the last step 

1 ) skip: erf = a\ ~a o 2 = o ' 2 

2 ) assn(a: := e): As er 3 ~a cr 2 , Vx.ai(x) cr 2 (a:). Let 
erj^a;) = v ^ 1 , cr 2 (a:) = uf 2 and 

^iW = Vi s a 2 (x) = v 2 

s. t. ki = Ai V ki = AA and kf = A' V ki = A'* for 

* = 1 , 2 . 

Let (ei, cri) JJ- uq 1 A (e 2 , cr 2 ) 1) w 2 2 
s. t. kf = Af V kf = AI* for i = 1,2. For low- 
equivalence of ei and e 2 , the following cases arise: 
a) kf = Af, s.t. (Af = Af) = A e E A A wi = w 2 : 

i) pc E Ai Ape E A 2 : By premise of assn rules, 
K = ((pc LI A e ) n Ai)*. By definition 03, 
of ~a o' 2 . 

ii) pc E Ai A pc E A 2 : kf = ((pc U A e ) n Ai)* 
and kf = pc U A e . As Af E Af, by defini¬ 
tion 04, af ~a o' 2 . 


iii) pc E Ai A pc E A 2 : fcf = ((pc U A e ) n A 2 )* 
and kf = pc U A e . As Af E A' 1; by defini¬ 
tion 05, af ~a of. 

iv) pc E Ai Ape E A 2 : kf = pc U A e and /cf = 
pc U A e . If pc E A and A e E A and ici = 
w 2 , by definition 03 1, of of. If pc E A, 
pcU A e E A. By definition 02, erf ~a erf. 

b) Af E A A Af E A: From premise of assignment 
rules, kf = pc U Af V fcf = (pc U Af )* V kf = 
((pcUAf)nAi)*. Similarly, kf = pcLlAf Vfcf = 
(pcUAf)*Vfcf = ((pcUAf)nA 2 )*. Since Af E A 
and Af E A, pc U Af E A and pc U Af E A. 
Therefore, from Definition [5]2, 03, 04 or 05 

of ~a of. 

c) kf = Af*: By premise of assn rules, kf = ((pc U 
Af)nAj)* or kf = (pcUAf)*. By definition03, 
of ~a of. 

d) kf = Af* A kf = Af: 

i) pc E Ai Ape E A 2 : By premise of assn rules, 
kf = ((pc U Af) n Ai)*. By definition 03, 
of ~A of. 

ii) pc E Ai A pc E A 2 : kf = ((pc U Af) n Ai)* 
and kf = pc U Af. From definition 04, 
Af E Af, so (pc u Af) n Ai E pc u Af. 
By definition 04, af ~ A af. 

iii) pc E Ai A pc E A 2 : kf = ((pc U Af) n A 2 )* 
and kf = (pc U Af)*. By definition 03, 
of ~a of. 

iv) pc E Ai A pc E A 2 : kf = (pc U Af)* and 
kf = pc U Af . If Af E A, so pc U Af E A. 
Else if Af E Af, then pc U Af E pc U Af. 
By definition 04, af ~ A af. 

e) kf = Af A kf = Af*: 

i) pc E Ai Ape E A 2 : By premise of assn rules, 
kf = ((pc U Af) n Ai)*. By definition 03, 
of ~A of. 

ii) pc E Ai A pc E A 2 : kf = ((pc U Af) n Ai)* 
and kf = (pc U Af)* . By definition 03, 
0 \ ~a o 2 - 

iii) pc E Ai A pc E A 2 : kf = pc U Af and kf = 
((pcU Af) n A 2 )*. (pcU Af) n A 2 E pcU Af. 
By definition 05, of ~a of. 

iv) pc E Ai A pc E A 2 : kf = (pc U Af)* and 
kf = pc U Af. If Af E A, so pc U Af E A. 
Else if Af E Af, then pc U Af E pc U Af. 
By definition 05, of af. 

3) seq: IH1: If <j\ ct 2 then a’{ a 2 
IH2: If a'{ af then erf erf 

Since cri a 2 , therefore, from IH1 and IH2 erf 
of. 

4) if-else: IH: If a L a 2 , (c,o\) JJ - pc uAl of, 

(c, a 2 ) JJ-pcu^i* erf and pc U Af = pc LI Af then 
of ~a of. 

• If Af E A, Af = Af and m = n 2 . By IH, erf 
of- 


If Af E A, then Af E A, pc U A® E A for 
i = 1,2. By LemmaU a± ~a erf and g 2 g 2 - 
T.S. erf ~.a 0 - 3 , i.e., (Vx.crf(x) ~ A a 2 (x)) 

Case analysis on the definition of low- 
equivalence of values, x. in <ji and U 2 - Let 
ai(x) = uf 1 and a 2 (x) = v 2 2 and crf(x) = v 1 1 
and erf (x) = v 2 2 

a) (fci = k 2 ) = A' E A A v\ = v 2 = v. 

— If fcf = Af A fcf = A' 2 , then as o\ ~a 
erf and a 2 ~a 7 f, by definition [5] 1 , A! = 
Af A u = v[ and A! = Af A v = v 2 . Thus, 
A[ = Af A v[ = v 2 , so (if (x) ~ A g' 2 {x). 

— If fcf = Af* A fcf = Af, then as a\ ~a 
af and (72 ~a < 72 , by definition 05 Af E 
Ai = A' and by definitional fcf = Af = 
A 2 = A ’. So, A'i E Af. By definition [34, 
a[(x) 7f(x). 

- If fcf = Af A fcf = Af*, then as a\ ~ A 
af and a 2 < 72 ,by definitional fcf = 

Af = A\ = A' and by definition [5] 5 Af E 
A 2 = A!. So, Af E Af. By definition [t]5, 
erf (x) ~a 

— If fcf = Af* A fcf = Af*, then by 
definition [33, af(x) ~ A af(x). 

b) (fci =A x gA)A (k 2 =A 2 % A): 

— If fcf = A'i A fcf = Af, then as ay ~a G '\ 
and <72 ~.a < 72 , by definition [ 32 , (fcf = 
A'i E A) A (fcf = Af E A). bo, af(x) ~a 
a'. 2 {x). 

— If fcf = Af* A fcf = Af, then as (ii ~a af 
and cr 2 ~a af, by definition[32 fcf = A' 2 E 
A. By definition [34, af(x) af(x). 

— If fcf = Af A fcf = Af*, then as g\ ~ a af 
and g 2 ~a ctE by definition [3 2 fcf = Af E 
A. By definition [35, af(x) af(x). 
If fcf = Af* A fcf = Af*, then by 
definition [33, af(x) ~a af(x). 

c) (fci = Ai* A k 2 = A 2 *) : 

~ If fcf = A i* A fcf = Af*, by definition [3 3, 
g'^x) ~a °' 2 (x). 

— If k[ = A'i A k 2 = A! 2 *, then as g\ ~a &i 
and g 2 ~a <7 2 ,by corollary[3 pcUA\ E A[. 
As pcUAf E A and by definition [3 2 , A[ E 
A. By definition [35, g[(x) < 7 2 (a;). 

— If k[ = A!i* A k 2 = A 2l then as 
< 7 1 g[ and g 2 ~a < 7 2 , by corollary [ 2 J 

pc U A 2 E A 2 . As pc U ^ E A and by 
definition [32, A 2 E A. By definition [34, 
g[(x) g' 2 (x). 

— If k[ = A'i A k 2 = A' 2l then as ay ~a 
and g 2 a ’2 , by corollaryEl pcUA\ E A\ 

and pcU A 2 E A 2 . As pc LI Af E A and by 
definition [32, A[ E A and A 2 E A. By 
definition [ 32 , g[(x) ~a g' 2 (x). 

d) (fci = Ai* A fc 2 = A 2 ): 


- A 2 E A : 

* If k[ = Af* A k 2 = Af*, by defini¬ 
tion's, crf(x) ~a g 2 (x). 

* If k[ = Af A k 2 = Af*, then as 
g 1 ~a a \ an d 7 2 ~a erf,by corollary [3 
pc U Af E Af. As pc u Af E A and 
by definition [32, Af % A. By defini¬ 
tion's, erf (a:) ~a CT f(a:). 

* If fcf = Af* A fcf = Af, then as 

g 1 ~a erf and g 2 ~a CT f, by defini¬ 
tion [32, Af E A. By definition [34, 
g[(x) g 2 (x). 

* If fcf = Af A fcf = Af, then as cti ~ a a i 
and g 2 erf, by corollary [3 pcLlAf E 
Af. As pc U Af E A and by defini¬ 
tion [32, Af E A. By definition [32, 
Af E A. By definition [32, erf (a;) 

erf (a;). 

— Ai E A 2 E A ; 

* If fcf = Af* A fcf = Af*, by defini¬ 
tion's, erf (a;) ~a A 2 {x). 

* If fcf = Af A fcf = Af*, then as 
g 1 ~a erf and g 2 ~a CT f, by corollary [3 
pc U Af E Af. As pc U Af E A, 
and by definition [32, Af E A. By 
definition [35, erf(a;) ~a crf(x). 

* If fcf = Af* A fcf = Af, then as G\ ~a 
erf and er 2 erf, Af E (pc U Af) I~1 Ai 
as pc U Af E A\ and Af = A 2 by 
corollary [I] and definition [3 1 - Thus, 
Af E Af. By definition [34, erf (a;) 

erf (a;). 

* If fcf = Af A fcf = Af, then as cri erf 
and g 2 erf, by corollary [TJ pcUAf E 
Ai. As pc U Af E A, by contradiction 
the case does not hold. 

e) (fci = Ai A k 2 = A 2 *): 

- Ai\£A: 

* If fcf = Af* A fcf = Af*, by defini¬ 
tion's, crf(x) ~a erf(x). 

* If fcf = Af* A fcf = Af, then as 
g 1 ~a G '\ an d 72 ~a 7f,by corollary [3 
pc U Af E Af. As pc U Af % A and 
by definition [32, Af E A. By defini¬ 
tion's, erf(x) ~a 7f(x). 

* If fcf = Af A fcf = Af*, then as 

71 erf and g 2 ~ a CT f, by defini¬ 

tion [32, Af E A. By definition [34, 

7f(x) ~.a 7f(x). 

* If fcf = Af A fcf = Af, then as cri ~>t erf 
and g 2 7f, by corollary [3 pcUAf E 
Af. As pc U Af E A and by defini¬ 
tion 02, Af E A. By definition [32, 
Af E A. By definition [32, erf(x) 

7f(x). 


— .4 2 E A-i 

* If k[ = A!i* A k' 2 = A! 2 *, by defini¬ 
tion [5]3, ai(x) ai(:r). 

* If k[ = A[ A k 2 = A'-/, then as a\ 

(j'i and a 2 ~a cr 2l A 2 E (pc U A 2 ) n _4 2 
as pc U A 2 E A -2 and A[ = Ai by 
corollary CD and definition 01. Thus, 
A 2 E A!i- By definition 05, a' x (x) 
a' 2 (x). 

* If k[ = Ai* A k 2 = A 2 , then as 

o i ^_4 g’ x and a 2 a 2 , by corollary 0 
pcU A 2 E A' 2 . As pc U A 2 E -4, and 
by definition 02, A 2 E A. By defini¬ 
tion 04, g[(x) g' 2 (x). 

* If k[ = A'i Ak 2 = A 2 , then as o\ a[ 

and a 2 a 2 , by corollary 0 pcUA 2 E 

A 2 ■ As pc U A 2 E -4, by contradiction 
the case does not hold. 

5) while-t: IH1: If ay cr 2 , (c,ai) §- pc uAl er", 

(c, a 2 ) § V cuA e a 2 and pc U AI = pc U A 2 then 
_// _// 

IH2: If a" a/,', (c,a") ^ pcU ^ (c,a 2 ) $ pc uAl 
a' 2 and pc U Af = pc U A 2 then ai c 2 • 

• If -4i E -4, A\ = A 2 and ni = n 2 . By IH1 and 

IH2, ai ^ a-E 

• If A\ E -4) then A 2 E -4, pcUAf E -4 for i = 1,2. 

By Lemma 0 ai a 7 / and a 2 ~ A o 2 . 

T.S. a" a 2 : By similar reasoning as if-else. 

As a'{ <t 2 , and by Lemma 0 a" ai and 

~A fJ 2 - 

T.S. ai & 2 : By similar reasoning as if-else. 

6) while-f: ai = ai ~ A 02 = cr 2 


